I think more than one drm init data can map to a single discontinuity sequence.

Thank you for taking a look at this pr.

more than one drm init data can map to a single discontinuity sequence

I coundn’t think of the situation of multiple init data in a single discontinuity sequence
Could you tell me how the playlist look like?
Do you mean we have to apply drmInitData until the next #EXT-X-KEY or the end of the playlist?

And one more thing.
As you explained here, you don’t want to use SparseArray?
If so, how do you want me to implement it?

Should probably be changed to

{@link DrmInitData} for sample decryption, or null if the segment's samples are not DRM-protected.

Nit (not sure it applies): Lines should not exceed 100 chars.

Is this a stray import?

Can we leave this as before?

There is an issue with this: If the first segment is not encrypted, then the media chunk will expose no DRM init data, and the track selector will think the segment is not encrypted. I'll try to think about a solution for this.

Sorry, I coundn't understand your concern.
I know the fact that shaka-packager creates a playlist like ↓ for a Widevine-encrypted content.
In that case, I believe that video_1.m4s is not (and should not be) encrypted and video_2.m4s ~ are encrypted with Widevine.
I think the track selector should think the segment is not encrypted, because it's not encrypted. 🤔

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-TARGETDURATION:18
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-MAP:URI="video_init.mp4"
#EXTINF:13.583,
video_1.m4s
#EXT-X-DISCONTINUITY
#EXT-X-KEY:METHOD=SAMPLE-AES-CTR,URI="data:text/…
#EXTINF:10.417,
video_2.m4s
#EXTINF:7.417,
video_3.m4s
…

The track selector does not know about specific segments, but rather about tracks. The issue is that the track is indeed encrypted (even if some of the segments are clear), but the first segment's format (unencrypted), as things are now, will be propagated as the track's format.

Thanks for the replay! I understood what you mean.

will be propagated as the track's format.

but, I could not find the exact place where the track selector thinks the segment is not encrypted or a wrong track's format is propagated.

you want to me to fix it on this PR?
I'm sorry to bother you, but it would be really appreciated if you could tell me the specific point where it's happening.

What I suspect might be a solution for this is keeping a DrmInitData in the media playlist which contains SchemeData's with null SchemeData#data, so as to signal that encryption of a specific CDM is eventually there, without tying it to a specific key/pssh. This DrmInitData would then be propagated by the period for the track selector to consume. This field would be populated by the playlist parser after parsing all EXT-X-KEYS present in the playlist.

I'm not sure about what you suggest.
Does your suggestion mean HlsMediaPlaylist should hold a single DrmInitData with null SchemeData#data? (Instead of letting each segment hold a DrmInitData)

and again, Im playing the content, which has the first non-encrypted segment and the other widevine-encrypted segments, and It plays without any problems, and could not find the place where wrong track's formats are created or propagated while breakpointing inside exoplayer.

Does your suggestion mean HlsMediaPlaylist should hold a single DrmInitData with null SchemeData#data

No, it should contain as many scheme datas as encryption schemes there are in the content. For example, if the media is encrypted using both Widevine and Playready, in would contain two SchemeDatas, one for each.

Im playing the content, which has the first non-encrypted segment and the other widevine-encrypted segments

This issue does not affect playback. We have a similar problem to the one introduced here in chunkless preparation (but unlike here, we cannot do much without downloading extra stuff, which defeats the purpose of chunkless preparation).

The issue is track selection. The tracks exposed by the MediaPeriod will not contain DRM data, so the track selector will assume the content is unencrypted. The resulting behavior is a crash instead of graceful handling of unsupported DRM schemes. In this case, you are playing on a device that supports the used DRM scheme. If it didn't, the player would crash instead (potentially -though rare- with a native crash). Hopefully this is clear.

Thank you for the explanation!.

The tracks exposed by the MediaPeriod will not contain DRM data

I think the place where the MediaPeriod exposes the tracks is here.

But, it seems like the MediaPeriod has the track groups with non-null drmInitData in it.

http://160.16.54.236:8081/drmtest/media/drm/180p/master.m3u8 is the stream that I tested .

{
  "name": "HLS Plain (180p)",
  "uri": "http://160.16.54.236:8081/drmtest/media/plain/180p/master.m3u8"
},
{
  "name": "HLS DRM (180p)",
  "uri": "http://160.16.54.236:8081/drmtest/media/drm/180p/master.m3u8",
  "drm_scheme": "widevine",
  "drm_license_url": "https://proxy.uat.widevine.com/proxy"
},
{
  "name": "HLS Plain (180p) -> DRM (180p)",
  "uri": "http://160.16.54.236:8081/drmtest/playlist/plain180p-drm180p/master.m3u8",
  "drm_scheme": "widevine",
  "drm_license_url": "https://proxy.uat.widevine.com/proxy"
},

And your solution is not clear to me yet.

keeping a DrmInitData in the media playlist which contains SchemeData's with null SchemeData#data

does your suggestion mean keeping an another DrmInitData only for the first segment like ↓?

  private static HlsMediaPlaylist parseMediaPlaylist(LineIterator iterator, String baseUri)
      throws IOException {
    ...
    String encryptionKeyUri = null;
    String encryptionIV = null;
    DrmInitData drmInitData = null;
    DrmInitData drmInitDataforFirstSegment = // drmInitData which contains SchemeData's with null SchemeData#data;

    String line;
    while (iterator.hasNext()) {
      line = iterator.next();
        ...
    }
  }